Ansätze der Forschung zur Unterstützung der Entwicklung von Softwarekomponenten

Das vorliegende Arbeitspapier entstand aus einem Vortrag, welcher im Rahmen einer Veranstaltung der Wirtschaftsinitiative "Baden-Württemberg: Connected" (bwcon) aus der Reihe "Forum Unternehmenssoftware" gehalten wurde. Das übergeordnete Ziel dieser Veranstaltung war, die zukünftigen Perspektiven – Chancen und Herausforderungen – komponentenbasierter Software für Softwarefirmen und -anwender aufzuzeigen und zu diskutieren. Der Beitrag der Universität Mannheim bestand darin, die aktuellen Ansätze der Forschung zur Unterstützung der komponentenbasierten Softwareentwicklung im Überblick darzustellen, insbesondere eigene Ansätze und Projekte zu diesem Thema vorzustellen und einen Ausblick auf zukünftige Entwicklungen zu geben. Die wichtigsten Punkte des Vortrags sowie die Ergebnisse der anschließenden Diskussionsrunde mit Anwendern von Unternehmenssoftware, Softwareherstellern sowie weiteren Wissenschaftlern auf diesem Gebiet werden in diesem Papier zusammengefasst

Eine Methode zur kollaborativen Anforderungserhebung und entscheidungsunterstützenden Anforderungsanalyse

Gegenstand dieses Beitrags ist die Entwicklung einer theoretisch fundierten Methode für eine kollaborative Anforderungserhebung mitsamt entscheidungsunterstützender Anforderungsanalyse

A Taxonomy of Metamodel Hierarchies

In the context of software engineering and model-driven development in particular, metamodeling gains more and more importance. So far, no classifying study of theoretical metamodeling concepts and hierarchy design options has been conducted in order to establish a comprehensive set of interrelated design variables, i.e. a coherent design space. A well-designed metamodeling hierarchy is essential to avoid problems not easily noticeable, like ambiguous classification and the replication of concepts. This study aims at exploring the theoretical foundation and providing a taxonomy or a design space for constructing tailor-made metamodel hierarchies for specific problems areas and domains

A method for collaborative requirements elicitation and decision-supported requirements analysis

As software systems become more and more complex with a multitude of stakeholders involved in development activities, novel ways of conducting the process of requirements elicitation and analysis are to be found. Therefore, this paper introduces a method for collaborative requirements elicitation and decision-supported requirements analysis. Accompanying this method, appropriate tools and techniques, both existing and custom-made, are referred to. The method is designed for a geographically distributed collaborative environment in order to support software manufacturers as well as IT departments which develop software solutions for multiple users or even consortiums of customers.1st International Workshop on Advanced Software Engineering: Expanding the Frontiers of Software Technology - Session 3: Software Development ProcessRed de Universidades con Carreras en Informática (RedUNCI

Ansätze zur kollaborativen Softwareerstellung

Die Erstellung von Software zur Unterstützung betrieblicher Abläufe wird in zunehmendem Maße komplexer. Da der Erstellungsprozess in der Softwareindustrie traditionell einer Werkstatt- bzw. Einzelfertigung entspricht, erfordert die stetig steigende Nachfrage nach betrieblicher Software und die fortschreitende Globalisierung die rationellere Gestaltung der Softwareentwicklung. In der Literatur werden daher immer häufiger die Industrialisierung der Softwareerstellung und neuartige Formen der Spezialisierung, Arbeitsteilung und Zusammenarbeit (engl. Collaboration) vorgestellt. Dabei kann im Wesentlichen unterschieden werden, ob die Zusammenarbeit einzelner Akteure und Arbeitsgruppen auf Projektebene oder die strategische Zusammenarbeit von Unternehmen innerhalb der Softwareindustrie behandelt wird. Über diese beiden grundlegenden Betrachtungsebenen hinweg lassen sich existierende Ansätze zur arbeitsteiligen Softwareerstellung entlang mehrerer Dimensionen, wie räumliche, zeitliche und organisatorische Verteilung der Aktivitäten im Prozess sowie Intensität und Richtung der Zusammenarbeitsbeziehungen klassifizieren. Ziel dieses Artikels ist es, einen umfassenden und systematischen Überblick über bestehende Ansätze zur kollaborativen Softwareerstellung zu geben, indem diese in einen generischen Klassifikationsrahmen eingeordnet werden. Des Weiteren soll eine etymologische und pragmatische Herleitung des Kollaborationsbegriffs die Etablierung eines eigenständigen Forschungsparadigmas im Rahmen der Wirtschaftsinformatik ermöglichen

Analyzing the Applicability of an Agile Methodology to Distributed Collaborative Software Development

Today, information technology (IT) has penetrated most domains of business and private life. The knitting of IT-systems and their dependencies are getting more complex every day. For businesses, this development can mean great opportunities. IT has become a main driver for competitive advantage and business success. On the other hand, misled software development (SD) projects can mean an existential threat to the operational and financial situation of a company. The efficient development of effective software is an essential part of optimally facing present and future challenges. Managing SD with traditional methodologies often leads to high planning and management overhead and still, severe schedule deviations and budget overruns cannot be eliminated. The sequential and plan-driven traditional approaches are often not able to support an adequate reaction to either internally or externally caused changes in requirements. Complex and unclear system landscapes with diverse interfaces, ambiguous customer requirements, changing business strategies or fluctuating legal requirements are just a few examples for possible sources of changing system requirements. Today, Extreme Programming (XP) is the most popular agile development methodology supported by the Agile Alliance. Its name was chosen because it claims to bring common sense to an extreme level. It focuses on communication, simplicity, feedback and courage, to improve the speed and quality of SD. Formal processes and documentation are neglected in favor of tacit knowledge to improve flexibility. Close communication between developers and the continuous integration of customer representatives are key components of XP. XP was initially developed for small to medium sized collocated development teams. This paper analyzes to what extent XP can be transferred to larger distributed developing endeavors. The focus is on XP, because it is the methodology with the highest congruence to the original Agile Manifesto. It does not claim to be all new, but to be an aligned composition of well established ideas and practices from other methodologies

Die Veränderung der Softwareerstellung durch Open Source

Zu Beginn der Computer-Ära war Software ein Gut, welches hauptsächlich als Zugabe beim Erwerb eines Computersystems gesehen wurde. Es existierten keine Softwarefirmen im heutigen Sinne, sondern die Software war ein Bestandteil der von den Hardwareherstellern angebotenen Produkte. Viele zusätzliche Programme wurden zu dieser Zeit von Anwendern für ihre eigenen Bedürfnisse geschrieben und oftmals als public domain zur Verfügung gestellt. Mitte der '70er Jahre trat hier eine Wende hin zu kommerziell vertriebener Software ein. Seit der Gründung der Free Software Foundation (FSF), 1985, entstand eine organisierte Gegenbewegung Hier haben auch die heute bekannte GNU/General Public License, unter der auch Linux vertrieben wird, sowie das gesamte GNU-Projekt ihre gemeinsamen Wurzeln. Mit Gründung der Open Source Initiative6 (OSI) 1998 und der damit verbundenen Veröffentlichung der ersten Version der Open Source Definition (OSD) wurde der Begriff „Open Source“ (OS), wie wir ihn heute kennen einer breiten Öffentlichkeit zugänglich gemacht. Die OSD (mittlerweile in der Version 1.9) ist selbst keine Lizenz sondern eine zehn Punkte umfassende Bedingung, die eine Lizenz erfüllen muss, um als OS Lizenz zu gelten. Hierbei stehen vor allem die freie Verfügbarkeit des Quelltextes und die uneingeschränkte Weitergabemöglichkeit der Software an sich sowie des Quelltextes im Besonderen im Vordergrund. Außerdem müssen eine Veränderung des Quelltextes und die Weitergabe der veränderten Quellen uneingeschränkt gestattet sein. Der Unterschied zwischen den Ansichten der FSF und der Open Source Bewegung (OSI) finden sich in deren unterschiedlichen Betrachtungsweisen der Softwarewelt. Für die Open Source Bewegung ist die Frage, ob eine Software quelloffen (open source) sein sollte, eine rein praktische und keine ethische. Eine nicht open source stehende Software stellt im Sinne der Open Source Bewegung lediglich eine suboptimale Lösung dar. Die OSI sieht ihre Aufgabe vor allem in der Verwaltung und dem Marketing der OSD. Für die FSF dagegen, stellt sie hauptsächlich ein soziales Problem dar. Der ursprüngliche Entstehungsweg eines Open Source Projekts ging bisher von einem einzelnen Entwickler aus, der mit einem bestehenden Produkt unzufrieden war oder für ein bestimmtes Problem keine passende Lösung fand. Eine „strategische Ausrichtung“ von OS war in diesem Kontext nur schwer möglich. Diese Begrenzung von Open Source beginnt sich heute allerdings immer weiter aufzulösen. Viele Unternehmen sehen in Open Source mittlerweile eine alternative Möglichkeit und Chance, die es sich lohnt zu fördern und voranzutreiben. Im Weiteren wird diskutiert, inwiefern Methoden der Open Source Softwareentwicklung (OSSE) auch auf Unternehmensebene, d.h. in einem kommerziellen Umfeld, zum Einsatz kommen können. Es geht nicht darum, eine qualitative, produktbezogene Untersuchung von Open Source Software (OSS) im Vergleich zu proprietärer Software durchzuführen, sondern den möglichen Nutzen von OSSE für Unternehmen, die Software herstellen, zu analysieren

Konzeption und Implementierung eines Werkzeugs für nutzenbasiertes Traceability- und Rationale-Management in verteilten Entwicklungsumgebungen

Unter Nachvollziehbarkeit (engl: Traceability) wird die Möglichkeit verstanden, verschiedene Artefakte (beispielsweise Anforderungen, Designdokumente oder Quellcode) so miteinander zu verknüpfen, dass stets nachvollzogen werden kann, welche Artefakte wie miteinander in Beziehung stehen. Die Nachvollziehbarkeit sollte hierbei sowohl vorwärts- als rückwärtsgerichtet möglich sein. Ebenso wichtig wie die Nachvollziehbarkeit der Beziehungen zwischen den Artefakten ist es, die Gründe festzuhalten, die zu Entscheidungen in der Softwareentwicklung geführt haben (engl.: Rationale Management). Werden diese Informationen festgehalten, so können beispielsweise auch dann noch Entscheidungen nachvollzogen werden, wenn der entsprechende Mitarbeiter nicht mehr verfügbar ist. Werden allerdings alle Traceability-Informationen festgehalten, so entsteht unter Umständen einen Überfluss an Informationen, der nur noch schwer zu durchschauen ist. Einige Anforderungen sind möglicherweise nicht so wichtig wie andere, werden diese aber gleichrangig neben den Wichtigeren dargestellt, so kann der Überblick verloren gehen. Daher sollte Traceability- und Rationale-Management nutzen- oder wertbezogen (engl.: value-based) betrieben werden. Unter dem Wert wird in diesem Zusammenhang der Nutzen verstanden, mit dem ein Nutzer der Software bzw. der Auftraggeber eine Anforderung bewertet. Die Bewertung einer Anforderung durch die Entwickler kann von der Bewertung durch die Anwender deutlich abweichen, daher sollte der Hauptfokus bei der Entwicklung auf dem Nutzen für den Kunden liegen. Durch die Verknüpfung der Anforderungen mit den zugehörigen Artefakten werden wichtigere Artefakte auf diese Weise automatisch höher priorisiert. Nutzenbezogenes Traceability- und Rationale-Management führt so unter anderem zu einem besseren Verständnis des Codes, zu besserer Wartbarkeit und Dokumentation, zur Qualitätssicherung, Fehlerreduktion und höherer Effizienz der Entwicklung sowie letztendlich zu höherer Kundenzufriedenheit. Ziel dieses Artikels ist es, die Entwicklung eines Werkzeug vorzustellen, das Daten über Anforderungen, Aktivitäten und Nutzer, die in einer kollaborativen Softwareentwicklungsplattform verwaltet werden, extrahiert und die Beziehungen dieser Entitäten untereinander visualisiert und analysiert. Dabei sollen entsprechend dem Wert der Anforderungen und daraus resultierender Artefakte wichtige Beziehungen besonders hervorgehoben werden. Zusätzlich sollen die Rationale-Informationen von verschiedenen Artefakttypen dargestellt und analysiert werden können

Analyse der Übertragbarkeit der Open-Source-Entwicklungsmethodik in den kommerziellen Bereich

Open Source-Software findet bereits seit einiger Zeit erfolgreich Einzug in die Unternehmenspraxis. Das quelloffene Betriebssystem GNU/Linux sowie der HTTP-Server Apache haben sich mittlerweile in vielen großen wie kleinen Unternehmen zu einem Standard etabliert. Eine wesentliche Grundlage für den Erfolg dieser und weiterer Open Source-Produkte bilden die entsprechenden Entwicklungsmethoden, die zur Unterstützung verteilter Zusammenarbeit innerhalb der Open Source Communities entstanden sind. Dies hat zur Folge, dass Einflüsse aus der Open Source-Welt auf zweierlei Arten in die Unternehmenspraxis diffundieren: Neben dem vermehrten Einzug von quelloffene Anwendungen in unternehmenskritische Bereiche einerseits führt die Tatsache, dass diese Anwendungen verteilt und quelloffen entwickelt werden, andererseits dazu, dass immer mehr Unternehmen dazu übergehen, die entsprechenden Methoden und Techniken auch in ihren kommerziellen Softwareprojekten einzusetzen. Vor allem Letzteres soll im Zentrum dieser Arbeit stehen

Evaluating the Applicability of Requirements Engineering Tools for Distributed Software Development

Requirements engineering (RE) is the first part of the software engineering process. It consists of distinct phases in which certain stakeholders deal with the problem of creating and maintaining a systems requirements document. This artifact should clarify what the customer expects from the system and how the developer should design it. RE is often mentioned as the most critical phase in the software development process. Mistakes made during the requirements phase can cost up to a hundred times more than coding errors. Moreover, The Standish Group International (2003) found out, that on average only 54%, of the originally defined features of a project are delivered and 45% of those features that are delivered are never used. Misidentified requirements are the most significant source of customer dissatisfaction with delivered systems. The problem of creating the requirements document is reinforced through geographical distance between the different people involved in the RE process. Not only the distance between customers or users and the engineers constitutes a problem, often the engineers themselves are distributed all over the world, e.g. due to outsourcing decisions and offshoring projects. The number of firms participating in global software development was low, but today 203 of the US Fortune 500 engage in offshore outsourcing endeavors. Today, more than 50 nations participate in collaborative software development projects internationally. The reasons are cost advantages and a large and well-educated pool of labor—India is a famous example. Although RE is always distributed in some way due to the distance between the different stakeholders, the term distributed RE is used to emphasize the distance between them, e.g. in global RE processes. Instead of using simple text files or diagrams for communicating both requirements and possible changes to them, nowadays a lot of tools from different vendors exist to help mastering the RE process. These tools belong to the class of so-called computer-aided software engineering (CASE) tools. Many tools support a multi-user environment that is needed for distributed RE. These tools are intended to help overcoming some of the problems mentioned before. Therefore, the aim of this paper is to give an overview over existing RE tools on the market and to evaluate how they support the different phases of RE - especially a distributed RE process. The paper is structured as follows: In chapter 2 the generic phases of the RE process are shortly described, followed by a short market overview of tools in chapter 3. The four market leading tools are evaluated in detail in chapter 4, supplemented by a short description of some interesting other tools, especially from smaller German providers. Finally, chapter 5 summarizes the results of the evaluation